EmuTOS on Y Ddraig

EmuTOS is a Free operating system for computers based on Motorola 680x0 or ColdFire microprocessors. It features functionality similar to TOS, which powered the Atari ST and its successors between 1985 and 1994.

EmuTOS is extremely flexible. It can run on real hardware as a ROM replacement, bootable floppy, standard executable, cartridge… It is available in 12 languages for 14 different variants. Of course, it also runs happily on any Atari emulator such as ARAnyM, Hatari, or Steem SSE. As Free Software, it can also be recompiled from sources to be completely customized._

This is something I wish I had documented in more detail at the time, and it’s something I intend to improve on for future projects. What follows is a broad overview of the work required to get EmuTOS running on Y Ddraig.

Bringing up EmuTOS on Y Ddraig #

I first looked at implementing EmuTOS several years ago, but at the time didn’t make much progress. A few months back Rob Gowin very kindly creating an initial version of EmuTOS for Y Ddraig based on his work of porting EmuTOS to his BITSY Mark I.

Using that port as a starting point, only a small amount of additional work was needed to get EmuTOS running on my hardware. After updating the serial code to match Y Ddraig’s UART implementation, I was greeted with the EmuCON console over the serial port. IDE disk access was working, and the system was functional enough to build the Stevie editor from source.

With a working serial console, the next goal was VGA output. Initially this was limited to text mode, which was already well tested on my system. Adding VGA console support was therefore relatively straightforward.

At this point EmuTOS was still usable over serial even with VGA output enabled, but to make the system standalone I needed keyboard input. I already had keyboard support for my own OS, so I expected this to be a quick task. In practice, EmuTOS exposed several issues in my keyboard initialisation and interrupt handling code.

After fixing these problems, I finally had a solid, standalone EmuTOS system running on Y Ddraig.

Desktop and GEM support #

Having the console based OS up and running was a great start, but the goal was to get the GEM based desktop up and running to have a nice graphical user interface.

EmuTOS includes its own basic GUI support, but rather than using that directly, I chose to add an fVDI driver. fVDI is a replacement VDI layer originally developed to provide accelerated graphics on Atari-compatible systems, allowing modern or custom hardware to expose high-performance drawing primitives to GEM applications. Given that my VGA card supports a 640×480 16-bpp bitmap mode, this seemed like a good fit.

Writing a basic fVDI driver turned out to be simpler than expected. For the very basic implementation of the driver, it requires implementing the c_write_pixel and c_read_pixel functions. With just those in place, the driver will quite happily draw the desktop and it looked great. Unfortunately, performance was extremely poor. Drawing everything one pixel at a time on a 10 MHz 68000 is painfully slow.

The fVDI source includes a 16-bit reference mode used by many existing drivers, the single read and write pixel functions are used as a fallback but it has more efficient drawing functions for fills and line drawing. While these help to make it a bit more useable, speeding up drawing many times over from the pixel drawing code, but performance still left a lot of room for improvement.

Around this time I also added mouse support. The keyboard controller I use includes mouse functionality, but it hadn’t been exercised before. Implementing mouse input exposed further issues in my original keyboard driver, leading to a fairly substantial rewrite. The only issue once that was working was the mouse didn’t seem to update on screen until it hit a UI element such as a menu which forced a redraw. With some help from people on Discord, I discovered that the mouse drawing routines are normally triggered from the vertical blank interrupt. Since I wasn’t generating that interrupt yet, adding it resolved the issue.

At this point I had a fully working, if still slow, GEM desktop.

Hardware acceleration #

Earlier versions of my VGA card included hardware-accelerated drawing functions, but these had been removed during a later simplification when I re-wrote the design to just text mode and a basic framebuffer. With fVDI now in place, it was clear that reintroducing some form of hardware acceleration would be essential.

While this improved the speed of things considerably, there are some drawing modes that EmuTOS uses, XOR mode when drawing, patterns and transparent pixels. These were the next tasks to implement. XOR was trivial in concept but required me to implement a read-modify-write cycle to the SRAM controller on the VGA card that involved a bit of a rewrite to the simple SRAM controller that I was using.

Patterned and transparent drawing are based on bit-per-pixel masks. Line patterns are passed as a word containing the bit pattern, but fill patterns were more complex. My solution was to implement a small fixed pattern ROM in the FPGA. The fVDI driver passes a pattern index, which selects one of these predefined patterns. Ideally this should be programmable rather than fixed, but it’s good enough for now and can be improved later

With these changes in place, both in the VGA hardware and the fVDI driver, the result is a GEM desktop with reasonable performance.

There are still improvements to be made. A hardware cursor sprite would avoid the overhead of software drawing, and there are additional drawing operations, such as bitmap blits, that would benefit from acceleration.

Overall, I’m happy with the performance and how things are working. There’s a few annoying random crashes and without knowing much about the Atari ST software ecosystem it took me a while to find some software than worked on EmuTOS without rely on hardware features.

Bonus proportional fonts #

One extra feature supported by fVDI is the use of FreeType to render TrueType fonts. Simply adding the FreeType source allows the driver to build with TTF support enabled.

The driver size jumps significantly so it probably requires a decent amount of RAM to run. The biggest downside with using TTF fonts becomes apparent on typing. The time to render a character on a 10Mhz 68000 seem to be 2 seconds. Fortunately characters are cached after rendering and it does make it a little more bearable, but at the end an interesting experiment but not practical for use.